Cream of the Crop 1/Cream of the Crop 1.iso/DESQVIEW/DESQCOMM.ARJ/COMMPROG.TEC

Text File | 1992-03-16 | 18KB | 323 lines

ID:CO Communications Programs and DESQview
Quarterdeck Technical Note #237
by Michael Bolton
March 16, 1992

DESQview provides true multitasking on any DOS PC in the Intel 86 processor
family, and on compatibles.  Users of communications software find this
feature particularly appealing, since other work can be done while large files
are being uploaded or downloaded.  The communications link remains unbroken
without sacrificing the entire computer to the on-line session.

There are a number of considerations involved with using communications
software under DESQview.  Many of these issues are complicated by the fact
that communications technology, and all of the various parameters which
surround it, can seem complex and obscure.


Q. What are COM ports and IRQs?  How do they relate to each other?

A serial port is a piece of hardware which can be used to move information to
and from the machine.  (When files or other forms of information are being
transferred FROM a machine, that machine is said to be "uploading"; when files
are being transferred TO a machine, that machine is "downloading".)  Unlike
parallel ports, which move information eight bits at a time (as a multilane
freeway moves cars), serial ports move data one bit at a time (as a single
lane roadway).  The initial design specification for the IBM PC called for a
single serial port, and this port was assigned a hardware Interrupt ReQuest
line, or IRQ -- very simply, a means of notifying the processor that attention
to a hardware device is required.  When an IRQ is asserted (or signalled), a
processor interrupt, also known as a software interrupt, is called.
Essentially, whenever a program or a piece of hardware asserts an interrupt,
it asks the processor to run a subroutine.   The processor runs a bit of code,
called an "interrupt handler", and then returns to where it was before. In the
case of a serial port that is receiving data, each byte coming into the serial
port causes a processor interrupt to be generated.  The processor stops
whatever it's doing and calls the interrupt handler, which inspects the data
at the serial port, and performs the appropriate action.  In the case of
high-speed communications (i.e., greater than 2400 bytes per second, or 2400
bps), this can be happening on the order of tens of thousands of times a
second.

Note that we have three things to keep track of here:  when something comes in
through (1) a serial port, it signals the processor's attention via (2) an
IRQ.  When the processor receives an IRQ, it executes a particular (3)
software interrupt.

An interrupt of higher priority can take immediate precedence over one of
lower priority; that is, an interrupt can interrupt another interrupt!  Other
pieces of hardware -- the keyboard and the system timer -- were seen as being
of potentially greater urgency than the communications port.  Consequently,
they were given IRQ lines with lower numbers, indicating higher priority.
Here's where life begins to get a little miserable:  COM 1 was thus assigned
to IRQ 4 at this time, and IRQ 4 was set up to call software interrupt 0C hex
(12 decimal).  So: COM1, using IRQ4, calls INT 0C.

Closer to the release date of the original PC, the designers found that they
had an IRQ line available, nothing to put on it, and at least a notion that it
might be desirable to have two serial ports on the machine.  COM 2 was
therefore planned.  The next free available IRQ was... IRQ 3 -- it had not yet
been assigned to a piece of hardware, although it had been assigned a
processor interrupt.  So:  COM 2 was assigned to IRQ 3, which calls INT 0Bh.


Later still, with mice and modems proliferating, and adventurous users
desiring more serial ports, the specs were augmented yet again.  Two more
serial ports (named COM 3 and 4) were clearly necessary, but there were no
Interrupt ReQuest lines available by which they could signal the processor
that they needed attention.  Consequently, it was decided that COM 3 and COM 4
would SHARE IRQs with COM 1 and COM 2.  That is COM 3 would be given IRQ 4,
and COM 4 would be given IRQ 3.  The chart makes this a bit easier to see.

Serial Port     IRQ     INT Hex (Decimal)
===========     ===     =================
  COM 1          4         0C    (12)
  COM 2          3         0B    (11)
  COM 3          4         0C    (12)
  COM 4          3         0B    (11)

Note that it is possible to have a system configured differently.  Many I/O
cards allow the user to associate communications ports with different IRQs.
However, the above are the default settings and are quite typical.  For
information on systems using more than two serial ports, you may require the
services of a FOSSIL driver.  This allows serial ports and IRQs to be
"multiplexed", or shared.  Information on FOSSIL drivers can be found on many
bulletin board systems and in some books on online communications.


Q. Does DESQview support serial communications programs?

As stated above, DESQview's support of multitasking makes it ideal for those
who wish to do other things while downloading is going on.  DESQview fully
supports high-speed communications, and provides a number of features for the
special handling that communications programs require.

Q. How should DESQview be set up for communications?

A. "Setup DESQview" Settings

Several settings are worthy of note in your overall DESQview setup.  The most
important two are found in the Setup DESQview / Advanced Options / Performance
section.


1) Optimize Communications should be set to Y.  This rotates the priority of
   the IRQs, which by default are given priority equivalent to their numbers.
   (Recall that the system timer is on IRQ 0  -- the lowest number and highest
   priority -- and the keyboard uses IRQ 1.)  When Optimize Communications is
   set to Y, the priority of IRQs is rotated, such that IRQ 2 typically gets
   top priority (unless there is a mouse attached), 3 is next, and so on, with
   0 and 1 receiving relatively low priority.  When DESQview sees a mouse
   attached to IRQ2, DESQview gives IRQ3 top priority, on the assumption that
   the that if you want to optimize communications, you want the serial ports
   to receive top priority.



   Optimize Communications can be set to a number as well; the
   number represents the IRQ (NOT the serial port) which is to be receive the
   greatest priority.


   If you are having difficulties with a modem on COM1, for example, it
   might be worthwhile setting Optimize Communications to 4 (for IRQ 4,
   representing COM 1).  In this case, IRQ 4 will get top priority, IRQ
   5 will be next, and so on.  Again, note that since the priority of
   the interrupts is merely rotated, and not reordered, setting Optimize
   Communications to 4 will give IRQ 4 the highest and IRQ 3 the lowest
   priority.  This is ideal for systems on which the modem is on COM 1
   (IRQ 4) and the mouse is on COM 2 (IRQ 3).  Without Optimize
   Communications, note that, in this case, the mouse would actually
   have higher priority than the modem!

   On a system with two modems -- one on COM 1 (IRQ 4) and the other on
   COM 2 (IRQ 3), an Optimize Communications setting of 4 would be
   terrible; IRQ 3 would drop to the bottom of the priority list, and
   thus the modem attached to COM2 could lose some of the incoming data.

2) It is important to make sure that the processor "sees" the
   communications port frequently, since the bytes coming in to the
   serial ports must be handled before the buffer on the communications
   port overflows.

   DESQview allocates time to each program via "Clock Ticks".  A tick is
   regulated by the system timer, which ticks 18.2 times every second,
   regardless of the type of processor.  DESQview runs a foreground
   application for n clock ticks, (where n is the setting under Setup
   DESQview / Advanced Options / Performance / Clock Ticks / Foreground)
   and runs EACH background application for the number of clock ticks
   allocated to the background setting.  The time in which an
   application runs is called a time slice.  An application is suspended
   while other programs are running in their time slices.  (Naturally, a
   program will not get a background time slice if it has been set not to
   run in background.)

   As an example, assume that we have four processes running on our
   machine, one of which is a communications program, and that
   DESQview's clock ticks setting is at its default 9 and 3.  In this
   case, the foreground application will have the processor's attention
   for 9 ticks (9/18.2 seconds), and two background processes will have
   3 ticks each (3/18.2 + 3/18.2 seconds), in between the 3 ticks
   allocated to our communications program.  This means that our
   communications program is getting the processor's attention once per
   second, for about 1/6 of a second; thus, the processor is otherwise
   occupied 5/6 of a second.  This is a long time for a communications
   program to be absent from the processor's attention.  Bytes coming in
   on the serial port can overflow the one-byte buffer in the standard
   UART chip, thereby causing some bytes to be lost.  Depending on the
   robustness of your communications software and the protocol it uses,
   lost bytes will result in a delayed transfer while the errors are
   corrected, corrupted files, or an aborted download.  The section
   below on the 16550A UART will have more to say on this subject.

   In fact, the situation isn't usually quite as bad as all that, since
   not every program takes its full slice all the time.  DESQview-aware
   programs inform DESQview whenever they have finished a task, and can


   therefore be suspended until there's more work to do.  Programs that
   have been written with no particular consideration for DESQview, are
   monitored while they are in the background -- when they do not have
   access to the keyboard.  If such a program is waiting for keyboard
   input, DESQview will abridge that program's time slice, and will not
   switch back to it until that program is put to the foreground again.
   And in fact, the situation is STILL better than the above might
   suggest.  DESQview manages all of the interrupt request lines by
   reprogramming the programmable interrupt controller chip.  When a
   hardware interrupt is asserted, DESQview determines which process
   needs urgent attention, and passes control to that program's
   interrupt handler.  DESQview also prevents timer, mouse, and keyboard
   interrupts from interfering while a communications interrupt is being
   handled, thus giving your program time to catch up and manage the
   incoming data.  If you have programs that are running in background,
   they may be suspended temporarily to improve the smoothness of
   communications; at the DESQview menu, type Rearrange / Tune
   Performance / Runs in Background / No.  If, despite all this, data is
   still coming in faster than it can be managed, adding a larger buffer
   to your serial port might help; see the section on the 16550A UART
   below.


B. DVP Settings

Three settings in your program's DESQview Program Information File
(accessed by the Change a Program Menu) are crucial for communications.

1) A communications program must be set to use the serial ports.  If the
   modem uses COM 1, Uses Serial Ports can be set to 1.  If the modem
   uses COM 2, Uses Serial Ports can be set to 2.  If the modem is on
   COM 3 or COM 4, or if you are at all unsure about which serial port
   the modem is on, set Uses Serial Ports to Y.  See Quarterdeck
   Technical Note #145 (COM3N4.TEC -- COM Ports and DESQview) for more
   information on this.

   In a given window, DESQview can hide a port by setting its I/O port
   address to 0, rather than to its actual address.

 When Uses Serial Ports is set to    DESQview hides the port address of
 ================================    ==================================
             1                                    COM 2
             2                                    COM 1
             N                               Both COM ports

   If a port is hidden in a given window, programs running in that
   window should be unable to access that port.  An exception to this is
   noted below, in the section headed "Programs that initialize the
   serial ports".  DESQview never hides the port address of COM3 or COM4,
   regardless of the "Uses serial ports" setting.

2) A communications program must be set to run in background.  Valid
   settings for Runs in Background are Y, N, or blank.  If the field is
   left blank, DESQview will continue to run a program in background if
   Uses Serial Ports is set to Y.

3) A communications program must be set not to swap out.  Valid settings
   for Can be Swapped Out are Y, N, and blank, but a communications
   program should be set explicitly not to swap out.  If the program is
   swapped out, it will be suspended.  If it is suspended, at very least
   data will be lost, and at worst, a system crash could result.

Other settings are important, too.

1) As with all programs running under DESQview, allocating enough memory to
   the program is important.  Many communications programs call on
   external programs -- most often to use download protocols which are
   not built-in to the program.  At the point where the external
   protocol is called, the application will typically need more memory
   than it has been using up to that point.  Take this into account when
   allocating memory usage in the DESQview Change a Program Menu.

2) Communications programs use "protocols" for file transfers -- these
   are schemes which govern how the connected computers relate to each
   other, how the information is organized, what error-checking routines
   are going to be used, and so on.  Communications programs typically
   support at least a few protocols directly, and often provide for
   other protocols to be added externally.  What typically happens is
   that such a program will allow the user to "shell out" to DOS
   temporarily, and start a program which handles the file transfer with
   the desired protocol.

   External protocols may cause a window to close prematurely if
   Close on Exit is set to Y.  When an external protocol finishes a file
   transfer, and issues a DOS Terminate Program call, DESQview may close
   the window in which the communications program is running.  If you
   are using an external protocol with your communications software and
   the window closes after a file transfer, try setting Close on Exit
   to N.  If you are using a batch file to load TSRs and a
   communications program within a DESQview window, you will find that
   the window remains open after the batch file has been completed; make
   "exit" the last line of the batch file.

3) A program which writes either graphics or text directly to screen must be
   configured not to do so if it is to run in background without corrupting
   the screen of foreground applications.

   a) The ideal is for a program to be "DESQview- or TopView aware".  Such
      programs write directly to screen normally, but write to DESQview's own
      video buffer when running under DESQview.

   b) Programs which write directly to screen often have configuration options
      which alter this strategy. Settings of this kind are often referred to
      as "uses DOS calls for screen writes" or "uses BIOS writes", or "do not
      write directly to screen".

   c) DESQview 386 is QEMM-386 and DESQview running together on an 80386 or an
      i486 processor.  Programs running under DESQview 386 can be
      "virtualized"; that is, DESQview 386 will intercept and properly manage
      the screen writes of programs that write directly to the video hardware.

   If none of these configurations is possible, there are two unpleasant
   prospects.  The first is that the program must be suspended while it is in
   background.  DESQview will suspend a background program that writes
   directly to screen:


   a) if "Runs in Background" is set to N or blank, AND
   b) if "Uses Serial Ports" is set to N.

   Suspending a communications program is unacceptable, since the essence
   of a communications program is to exchange information continuously.
   DESQview will therefore keep running a background program that
   writes directly to screen:

   a) if "Runs in Background" is set to Y, OR
   b) if "Runs in Background" is blank AND Uses Serial Ports is Set to 1, 2,
      or Y

In this case, the program will continue to write directly to screen while in
background, thus corrupting the display of foreground applications.  If you
are not using DESQview 386, and if your program writes directly to the screen
and cannot be dissuaded from doing so, you will be forced to tolerate the
corrupted display or to change your communications software to a package that
does not write directly to the screen or is DESQview-aware.  See the files
DIRECTLY.TEC and VIRTUALI.TEC for more information on display and
virtualization.

  ************************************************************************
  *This technical note may be copied and distributed freely as long as it*
  *is distributed in its entirety and it is not distributed for profit.  *
  *         Copyright (C) 1991-2 by Quarterdeck Office Systems           *
  ************************ E N D   O F   F I L E *************************